Design review happens before the merge.

Reviewing a screenshot of someone's laptop

Tessel makes scheduling software for dental practices: the appointment book, the recall reminders, the screen a front-desk coordinator looks at for eight hours a day. Six designers work alongside 22 engineers in Columbus, and until January the designers saw most changes for the first time after they had merged.

The process was a screenshot. An engineer finished a branch, captured the page from localhost, and pasted it into the pull request. The seed data on a laptop had four patients, all of them named Test. A real practice has a Tuesday with 61 appointments, three hygienists and a patient whose last name runs to 24 characters.

"We approved things that looked fine with four rows," says Jordan Ellis, a staff engineer. "Then it merged, a designer opened staging, and we wrote a second pull request to fix the first one." Tessel counted. In the last quarter of 2025, four in ten front-end pull requests were followed by a fix within the week.

What they changed

Ellis added Canary to the main repository in the second week of January. The app is a Next.js front end over a Django API, both already described in a Compose file, so the build worked on the first push. The part that took thought was data. A preview is only worth a designer's time if the appointment book looks like a real one, and a real one is full of patients.

database:
  engine: postgres@16
  seed: snapshot://nightly
  mask: [patients.name, patients.phone, patients.birth_date]

The first masked snapshot was wrong in an instructive way. Every birth date had been replaced with the same placeholder, so the pediatric recall view, which groups patients by age, showed one enormous group of identical children. Ellis changed the rule for that column from replacing the date to shifting it by a random number of days, and the view looked like a practice again. The names, phone numbers and dates are masked on the runner in Tessel's own cloud, before any preview reads them. The masking rules live in the same file as everything else, so the change went through review like code.

Mina Castellanos, who leads design, then made one rule: a front-end pull request is not ready for review until a designer has opened the link in Canary's comment. Since July, the comments designers pin to the page land on the pull request by themselves.

What happened

• 71% of pull requests are now reviewed by someone who does not write code: a designer, QA, or one of the two former office managers on the support team.
• Follow-up fixes after merge are down 43%.
• The median time from a push to a designer opening the preview is 9 minutes.

Castellanos says the comments changed more than the timing. On a screenshot, a designer could only say whether the picture matched the mock. In a preview they resize the window, tab through the form, and book a patient with a very long name into a very short slot. "Most of what we catch now is behavior," she says. "None of it was ever in a screenshot."

Tessel's pull request template still had a Screenshots heading until March. Ellis deleted it. The team's setup notes for new repositories are now four lines long, and the first one is the Compose file.